With the new wireless devices (UE), e.g. smart phones, the network traffic has exploded creating a big challenge for the network operators. From all the services run by user terminals (UE), video streams make up one of the largest segments of data traffic in communications networks and it is expected to continue growing in the coming years.
The wireless device (UE) may be a device by which a subscriber may access services, applications, or the like, offered by an operator's network and services and applications outside the operator's network to which the operator's radio access network and the core network provide access, as, for example, access to the Internet. The UE may be any wireless device, mobile or stationary, that is enabled to communicate over a radio channel in the communications network, for example but not limited to a user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) devices, smart watches, or any type of consumer electronics, for example, television, radio, lighting arrangements, tablet computer, laptops or personal computers. The wireless device may be portable, pocket storable, hand held, computer comprised or a vehicle mounted device, enabled to operate voice and/or data, via the radio access network, with an outer entity, such as another wireless device or a server.
Some years ago, the provisioning by telecommunication network operators of video services to user terminals (UE) subscribed to said operators was traditionally accomplished by so-called “walled garden” solutions, in which, in essence, these services were provided from servers under the domain of the network operator, and thus under its direct control. This trend has changed dramatically in recent years. Nowadays, most of the video services consumed by a user terminal, e.g. a mobile user terminal subscribed to a certain telecommunications network (operator) are provided by the, so-called, Over The Top service providers (OTT), which are independent of the telecommunications network operator to which the owner of the user terminal is subscribed, but which use the network infrastructure of network operators to provide services (e.g. video services) to the user terminal connected/subscribed to them. Examples of such OTTs are, e.g., YouTube or Netflix.
Presently, video services are generally delivered through a HTTP protocol (in contrast with other protocols like RTSP/RTP which are gradually declining). Within the HTTP protocol for video delivery, there is a trend of moving from HTTP Progressive Download (PDL) towards the more optimized HTTP Adaptive Bit Rate (ABR) streaming protocols, like: Apple HLS, Microsoft Smooth Streaming (MSS), Adobe HDS, DASH, or the like.
Network operators aim to minimize the impact of video traffic/streaming in their telecommunications networks. To avoid, for example, network congestion and/or overload situations due to the increased video traffic, different techniques are used today: trans-rating, trans-coding, video pacing, etc. For example, a video clip can be trans-rated from the original 1024 kbps to 300 kbps, which has negligible impact on the end-user experience on a small screen device.
HTTP ABR protocols natively support delivery optimization techniques which are directly handled by the end points (UE and HTTP server). Although the HTTP ABR protocols, such as mentioned above, have some differences, they have the following characteristics in common: Media streams (video streams) are prepared (e.g., encoded) beforehand by the media server, so that several video versions (e.g. with different encodings) of the same media stream (i.e. the same media stream content, the same media stream information) may be prepared, and are referenced by a “descriptor file”, each version with its corresponding identifier (e.g., descriptors/locators (URL)). Then, (i) the server sends to the UE the “descriptor file” that defines the characteristics (e.g., format, encoding, duration . . . etc.) and a corresponding identifier (e.g., descriptor/locators (URL)) of different media streams that represent the same media information (i.e. the same video, but with respectively different quality characteristics for example), and (ii) the user terminal (UE) selecting—by the own criteria of the UE (e.g., the UE's own processing load, the UE's perceived/detected bandwidth, etc.)—one of the media stream identifications, for example one of the descriptors/resource locators (URL) contained in the received “descriptor file”. This procedure defines a UE controlled manner for downloading media via a telecommunications network.
In other words, before the actual video delivery takes place, the HTTP video server sends to the UE a “descriptor file” that defines the characteristics (format, encoding, duration . . . etc.) and descriptors/locators (URL) of the different media streams that represent e.g. the same media information (i.e. each with a different characteristics). Subsequently, the UE parses the descriptor file and selects the video characteristics (format, encoding, etc.) and, for example, the URL including the corresponding media streams based on network conditions (i.e. as perceived by the UE) and/or the terminal characteristics. The above is selected before actual video delivery and may also be dynamically changed during the video session, so that e.g. the video quality may degrade gracefully when the UE cannot keep up with higher bitrates for any reason (e.g. the transmission resources of the network are overloaded and cannot provide enough bandwidth to the UE, and/or the processing or playing resources of the UE are overloaded).
3GPP TS 26.247 (V13.0.0) defines details of the aforementioned DASH protocol. More precisely, in chapter 10 (titled “QoE for Progressive Download and DASH”) a mechanism is defined for UE to deliver QoE reports for video delivered through DASH protocol to the web server.
Communications networks supporting the 3GPP TS 23.303 (V13.1.0) Policy and Charging Control architecture (PCC) are able to handle video services QoS and attempt to avoid network congestion and/or overload situations by establishing policies for video services where dedicated bearers with QoS are established. While video streaming over dedicated bearers with guaranteed bit rates are unlikely to suffer from congestion, video services used over the top may not be mapped onto dedicated radio bearers but are rather mapped to best effort radio bearers. In that case, video clients may compete for the same resources and also compete with other traffic (e.g., FTP, Web). Hence, congestion may occur which degrades QoS.
The PCC architecture that supports Policy and Charging Control functionality is illustrated in FIG. 1. This Figure has been taken from TS 23.203 (V13.1.0), which specifies the PCC functionality for Evolved 3GPP Packet Switched domain, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. More specifically, FIG. 1 shows the following relevant elements:
1) A PCRF (Policy and Charging Rules Function) node is a functional element that performs policy control decision and flow based charging control. A node implementing a PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF node 20 (described later).2) A SPR (Subscriber Profile Repository) node is a functional element that contains all subscriber/subscription related information for the subscribers of a network operator. The information is needed—among other purposes—for determining subscription-based policies and IP-CAN bearer level PCC and/or application detection control (ADC) rules by the PCRF. The SPR node 50 may be implemented by a single node, or their functionality may be distributed among a plurality of nodes (e.g. a distributed database system).3) A PCEF (Policy and Charging Enforcement Function) node that encompasses service data flow detection, policy enforcement and flow based charging functionalities. The PCEF functionality is commonly implemented by nodes interposed in the routing path of the data IP packets sent to and/or received from UEs connected to a telecommunications network (examples of said kind of nodes are: “Gateway GPRS Support Nodes”-GGSN-, or “Packet Data Network-Gateways”-PDN-GW-).4) A TDF (Traffic Detection Function) node is a stand-alone deep packet inspection (DPI) node introduced in 3GPP Rel11. In short, a TDF node handles application traffic detection, as per request from the PCRF node, as well as reports about the detected application traffic along with service data flow descriptions, if deducible, to the PCRF node, if requested by the PCRF node. Here, in addition to the IP header, the—as such known—DPI technology may also examine the data (payload) part of an IP packet as it passes an inspection/interception point to decide whether the packet may pass, needs to be routed to a different destination, for the purpose of collecting/detecting information or the like. In particular, DPI comprises inspecting/analyzing the contents of the IP data packets beyond the—so called—IP 5 tuples. The IP 5 tuples consist on the heading elements of an IP data packet comprising: IP source address, IP destination address, source transport address, destination transport address, and protocol over IP (e.g. TCP, UDP, SCTP). Therefore, the DPI technology consists, in short, in inspecting and analyzing the application layer information conveyed by IP data packets. As a result of the DPI analysis, service classification information may be obtained, which consists on IP packets being classified—i.e. after DPI processing—according to a configured tree of rules so that they are assigned to a particular service session.5) The Gx reference point is defined in 3GPP TS 29.212 (V13.2.0) and lies between the PCRF node and the PCEF node. The Sd reference point (Sd) is defined in 3GPP TS 29.212 (V13.2.0) and lies between the PCRF node and the TDF node.